software requirements blog

Welcome to our Newsletter!

Hi, [fname] -

I work with agile teams and most of them are implementing large software products. In this month’s eNewsletter, I share how to develop requirements on large agile projects – just enough requirements, just in time.

~ ellen

Ellen Gottesdiener,
President and Principal Consultant
EBG Consulting, Inc.
http://www.ebgconsulting.com

PS: Be sure to whitelist (add to safe sender list)
ellen@ebgconsulting.com. Otherwise you may not receive our “Success with Requirements” eNewsletter.

In Microsoft Outlook go to Actions>Junk Email - Add recipient to safe
senders list
In AOL, select "Add Address"
In Yahoo! Mail, Outlook or Outlook Express select "Add To Address Book"
In Hotmail or MSN, select "Save Address(es)"
In Gmail go to Contacts and select add address

In this issue:

Agile Requirements in Context eLearning

eLearning, Blended Classrooms, and Public Offerings

Upcoming Events

Resources of Interest

Archive Issues

Agile Requirements, In Context

As I discussed my August eNewsletter (see the link to the archive, below), there's a lot of hype about the role of requirements in agile projects. Many people think you don’t “do” requirements on an agile project. Hogwash. Indeed, agile projects use requirements—but just enough requirements at just the right time.

Agile requirements need to be understood in context of the product, release, and iteration.

Consider iterations, a key attribute of agile projects. How can you usefully define an iteration without developing some requirements? At what point in your project will you realize, retrospectively, that the rework involved in refactoring your architecture outweighs the time it would have taken for you to understand the big picture—something you get when you do requirements right?

I work with clients adopting agile practices. One of the greatest challenges is scaling agile practices when you’re building and enhancing large, complex software products. This issue surfaces early in a project, when the team has to decide which slice of the application to build for the first iteration.

In complex products, a good approach is to exploit one of agile’s greatest strengths: the imperative to reduce risk and increase learning as soon as possible. By building a small slice of the product and getting feedback on it immediately, teams quickly and inexpensively expose technical unknowns, while customers discover and explore true needs (requirements).

Balancing Business and Technical Value
But just jumping into building a slice the application can be risky in andof itself. How do you know where to start? The customer may believe there is a great need for certain user requirements to be satisfied, and indeed there may be. Some teams discover that, depending on the product, you can’t fully satisfy some user requirements until you build a subset of nonfunctional requirements or set up a technical infrastructure.

Another phenomenon on large projects with multiple teams is the discovery, after “sprinting” (e.g., iterating) two or three times, that the different teams need the big picture to better coordinate their work.

The trick is balancing business need with technical feasibility.

An effective solution is to hold a series of interlocking workshops to deliver requirements-driven roadmaps and product plans. These workshops work on three levels: product, release, and iteration. They involve the project community—the technical team and the business customers (product owners). This is illustrated here.

Product Workshop
Start with a product workshop to define your vision, the project scope, and a product roadmap. In this workshop you define which product features you will release over time. This workshop is done once for the product and serves as a guidepost for subsequent releases and iterations.

Identify the vision you have for the product, documenting it in a vision statement, a product “box,” or a metaphor. From there, define product scope using scope-level analysis models such as a context diagram, a list of events, conceptual entities, or a list of features in and out of scope.

Then, armed with this high-level understanding of the product, you create a product roadmap that reflects both a wide and a narrow view of the requirements that are needed to satisfy the product vision over time.

To create your product roadmap, group your scope-level requirements into feature categories (e.g., ordering, reporting, performance, etc.). Then analyze their interdependencies and their business value. Many teams do this by writing high level stories (i.e., epics) on cards and arraying them on the wall. Some teams use high-level use cases (i.e., named user goals, each with a one or two sentence description). The team needs to decide which portions of which features will be delivered in each release and determine a release schedule (perhaps two to four months).

Your goal is to gain understanding of the big picture – as a project community. Define the scope at a high level, using analysis models. Build your roadmap in a collaborative fashion, bringing together the product owners (business stakeholders) and the delivery team (technical stakeholders). I like using workshops as the venue for making this happen.

Release Workshops
For each release, create a release plan to define what will be delivered for a release. Each release will implement a subset of features, taking into account both business need and architectural dependency.

Releases tend to last three to six months and incorporate three to six iterations. Any given release plan is based on your understanding of requirements at this early point. You will need to conduct this release planning workshop for each release, roughly every two to four months for large products.

A requirements-driven release plan includes scenarios or stories (or lightweight use cases), a first-cut data model, quality attributes or quality attribute stories, and perhaps personas or actors. To understand dependencies, you can use pre- and post-conditions on events (or scenarios), allowing you to sequence the functionality of your iterations appropriately. Your context diagram should be used to define interfaces that need to be built into a release.

Iteration Workshops
Each iteration starts with an iteration planning workshop in which the team decides what requirements from the requirements backlog to deliver in the iteration - given team capacity, risks, and product development status. The iteration planning session also incorporates feedback from the prior iteration’s demo and retrospective.

Your iteration planning workshop includes documentation of user requirements (such as stories or scenarios), quality attribute stories or story “doneness” expressed as quality attributes, integration stories, and any technology or tool-related tasks that need to be completed. Some stories will need to “right-sized” and re-prioritized during the workshop.

After each iteration planning workshop, the team holds one or more informal requirements workshops to develop requirements for the current iteration. These workshops focus only on the requirements for the current iteration. They may be very informal (such as whiteboard or flipchart modeling sessions), or more formal and require pre-planning (such as when multiple product owners or members of other related teams must be present).

Outside the workshop, a business analyst or product owner should start requirements exploration for the next iteration (working one iteration in advance, to jump-start the next iteration planing workshop) while also supporting requirements definition and testing in the current iteration.

Recurring Retrospectives
An essential element of all these workshops are retrospectives. These workshops give you feedback on both the work product and the team process. Remember: you’re not doing agile unless you’re doing retrospectives! And even if you’re not currently using agile approaches, retrospectives are an essential tool for any business and technical professional.

Requirements Matter
Agile projects can't abandon requirements development and management. Agile projects need requirements. A requirements-driven—albeit lightweight—approach to large agile projects saves time and money and accelerates the team’s ability to deliver the right product, sooner.

Agile on large, complex products means you develop the necessary level of requirements to meet the needs of the successive level of stakeholders. Each level delivers what is useful to the next level – and not more. In this way, you lighten and tighten requirements develop to fit the rhythm of agile delivery, in context of product, release, and iteration.

~ ellen

Standard citation for this article:
Ellen Gottesdiener, “Agile Requirements, in Context,” Success with
Requirements, Vol. 2, No. 1(2008).

eLearning, Blended Classroom, and Public Offerings

Take self-paced eLearning, or optionally combine it with our expert instructor-led training for our unique "blended classroom" offering. Discount information for you, a subscriber to Success with Requirements, is provided below.

1. Self-paced eLearning: Roadmap to Success: Foundation for Requirements Development and Management.

This content rich and engaging training includes:

Long-term access (45 days) to the "Roadmap to Success:Foundation for Requirements Development and Management" curriculum

A copy of the industry's "go to" book on requirements: The Software Requirements Memory Jogger

Downloadable templates and printable tips to use on the job for years to come

Click here to learn more or register. Subscribers to Success with Requirements receive special pricing. Use DISCOUNT CODE: RFRTS05.

2. Blended Classroom: Roadmap to Success: Comprehensive. We are offering this unique, blended training publicly in two locations:

March 26-27, 2008: Indianapolis, Indiana

April 16-17, 2008: Orlando, Florida

This unique blended learning experience includes all the items listed above (Roadmap to Success: Foundation for Requirements Development and Management) PLUS:

Two days of instructor-led training in "Analysis Modeling" Course guide for "Analysis Modeling"

Mini-poster of the Requirements Roadmap

Continental breakfast, lunch, snacks for the two-day

Instructor-led training event

Completion certificate

Click here to learn more or register. Subscribers to Success with Requirements receive a 10% discount. Use DISCOUNT CODE: RCRTS05.

Project Management Training
Fellow “Memory Jogger” author, Karen Tate (The Project Management Memory Jogger and The Advanced Project management Memory Jogger has a generous discount on upcoming public offerings of Griffin Tate Group’s (GTG) project management training for “Success with Requirements” subscribers:

1. Structuring Successful Negotiations

This course focuses on building these essential skills and outlines their importance to project and program management success or failure. It delves into the key stages of a negotiation: analysis, determining your BATNA, planning the negotiation meeting, the negotiation, and negotiation tactics and strategies.

Upcoming offerings are in:

Atlanta (February 20)

Cincinnati (March 13)

Success with Requirements eNewsletter subscribers offering get a discount with this link.

2. Project Leadership: A Practical Guide to Communication, Influence, and Collaboration.

This workshop helps project leaders and project team members improve their skills in the following areas: communicating within the team and outside of the team, making decisions as a team, avoiding or resolving conflict, understanding and working with diverse thinking and learning styles, providing constructive feedback, and running effective meetings. Attendees will also learn how to obtain the support of project sponsors and management and the commitment of project team members using influencing skills and improved communication.

Upcoming offering is in:

Atlanta (June 25-26)

Success with Requirements eNewsletter subscribers get a discount with this link. 

Upcoming Events

2. Ellen will be teaching the instructor-led portion of our new blended classroom (self-paced combined with instructor-led) offering, Roadmap to Success: Comprehensive Foundation and Analysis Modeling in Indianapolis (March 26-27, 2008). See more info above on reader discounts. Register early to reserve your spot, class size is limited!

3. Mary Gorman will be delivering two full-day workshops and a presentation at Business Analyst World/Project World, Toronto (April 14-19, 2008).

4. Ellen will present the instructor-led portion of our blended classroom offering, Roadmap to Success: Comprehensive Foundation and Analysis Modeling in Orlando (April 16-17). See more info above on reader discounts. Register early to reserve your spot!

5. Mary will be presenting two full-day workshops and a presentation at Business Analyst World/Project Summit, Philadelphia, PA (April 28-May 1, 2008).

Resources of Interest

Each month we'll provide a few resources we think are worthwhile. The resources below relate to the topic of the featured article, agile planning and requirements and the role fothe business (product) owner.

I welcome your comments and suggestions for future issues!

Hubert Smits excellent article “Five Levels of Agile Planning: From Enterprise Product Vision to TeamStand-up” is a must read (note: sign-up to Rally Software’s portal to access the paper is necessary).

The essential reason why a product roadmap is needed is discussed in this article by Jacques Murphy, “The Product Roadmap to the Promised Land”

The product roadmap is laid out based on the product vision. Who owns the vision? Jim Shore discusses the vital role the product manager (a.k.a., the product owner in Scrum).

Read a brief summary of how eXteme Programming (XP) (an agile method) employs a release plan.

Archive Issues

Visit our archive to read our prior issues

Publication & Reprint Information

I invite you to reprint material from Success with Requirements in other electronic or print publications provided this copyright notice ("Written and edited by Ellen Gottesdiener, copyright EBG Consulting, Inc., [year]. All rights reserved.") and a link to http://www.ebgconsulting.com/ is included in the credits. Please send us copy of the publication that includes our reprint, along with a cover note referencing that it is a reprint.

Success with Requirements is a trademark of EBG Consulting, Inc.

Privacy & Subscription

This newsletter is sent only to confirmed "double opt-in" subscribers who have signed up at http://www.ebgconsulting.com/, or who have emailed a request to be added.

EBG Consulting, Inc. does not sell, rent, or loan subscriber information to any third party.

Welcome to our Newsletter!

Hi, [fname] -

Ellen Gottesdiener,
President and Principal Consultant
EBG Consulting, Inc.
http://www.ebgconsulting.com

In this issue:

Building Trust with Good Requirements Practices, Part 1

Latest EBG Publication in Crosstalk

Upcoming Events

Resources of Interest

EBG Agile Offerings

Archive Issues

Building Trust with Good Requirements Practices, Part 1

To work together effectively, the members of a team need to trust one another.

When you're developing product requirements, the issues at play include meeting deadlines, controlling cost, delivering the solution, incorporating changes, and ensuring quality. There are plenty of opportunities for trust to break down. Without trust, there may be hidden agendas, rumors, gossip, whining - even subversive behavior.

Johann Rost (2004) reported subversive behavior by team members, such as lying, withholding or delaying access to information, providing misleading or vague answers, and supplying poisoning ideas. Clearly, these projects are suffering from lack of trust which can result in project churn, team turnover, low morale, and unhappy customers.  

Reina and Reina (2006) identified three types of trust needed in organizations:

Contractual trust. As you might expect, this kind of trust is based on an unstated "contract": you will look out for my best interests, and I will look out for yours. If things change, we will renegotiate. Ultimately, we are jointly responsible for our success.
 

Communication trust. This kind of trust calls for honest and frequent communication. Team members share information, tell the truth, admit their mistakes, maintain confidentiality, and seek and provide feedback. Their actions are consistent with their words, and vice versa.
 

Define the Product Vision and Scope

One way to build trust is for the stakeholders to define a product vision statement. This document tells team members what they need to build, for whom they need to build it, and how it's different from what exists today.

Your vision statement builds contractual trust by establishing shared goals for business and technical staff. If the team can't agree on this document, you're not ready to plan and build the product. 

Involve the Stakeholders

A first step for defining requirements is to identify stakeholders and other sources of requirements information. This includes a wide variety of people: product owners and champions, developers, subject matter experts, business analysts, project managers, and specialists in testing, QA, auditing, regulatory issues, training, sales and marketing, and so on. 

Keep a Glossary

The glossary defines the meaning of the business terms in your product domain. Project teams need to speak the same language, building competency and communication trust. 

Set Criteria for Prioritizing Requirements

Software teams need a method for evaluating and filtering requirements. This practice builds contractual trust and eases communication.

For low-risk, simple projects you can prioritize requirements by assigning a general rank (such as high, medium, and low). For larger, more complex projects, you should precisely define the business value of each ranking.

Deciding What to Build Can Build Trust

A team's ability to explicitly establish and sustain the three types of trust - contractual, communication, and competence - at the start when they are deciding what to build - is an early and critical indicator of project success.

In a later newsletter I'll talk about other proven methods for building trust as you elicit requirements for your software projects.

~ ellen
 
References

Gottesdiener, Ellen. The Software Requirements Memory Jogger:  A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements, GOAL/QPC, 2005.

Gottesdiener, Ellen. "You Know When It's Not There: How Trust Enables and Enhances Collaboration," Cutter Journal, Vol. 20, No. 8 (August, 2007)

Reina, Dennis S., and Michelle L. Reina. Trust & Betrayal in the Workplace: Building Effective Relationships in Your Organization. 2nd edition. Berrett-Koehler Publishers, 2006.

Rost, Johann. "Political Reasons for Failed Software Projects." IEEE Software, Vol. 21, No. 6, November/December 2004, pp. 104, 102-103.

Latest EBG Publication in Crosstalk

We are pleased to announce our latest feature article, "Good Practices for Developing User Requirements" in the widely distributed Software Technology Support Center's Crosstalk Journal. You can read the issue online here.

Upcoming Events

1. Mary Gorman will deliver two full-day tutorials and a presentation at Business Analyst World/Project World, Toronto (April 14-19, 2008).

2. Mary will deliver two full-day tutorials and a presentation at Business Analyst World/Project Summit, Philadelphia, PA (April 28-May 1, 2008).

3. Paul Reed will be delivering a full-day tutorial and a presentation at ProjectWorld/World Congress for Business Analysts, San Diego, CA (June 24-27).

Resources of Interest

Read more about building trust in this article by Dennis and Michelle Reina (referenced in this eNewsletter's article).

In his classic 1986 essay "No Silver Bullet…" Frederick Brooks explains why the "soft stuff" is so hard in software engineering.
 

Making decisions explicit and using a collaborative process to reach them is essential for building trust. I discuss the why's and how's in my article "Decide How to Decide."
 

EBG Agile Offerings

EBG offers training and coaching services in using agile techniques for our clients transitioning to, as well as currently using, agile methods:

Archive Issues

Visit our archive to read our prior issues

Publication & Reprint Information

Success with Requirements is a trademark of EBG Consulting, Inc.

Privacy & Subscription

This newsletter is sent only to confirmed "double opt-in" subscribers who have signed up at http://www.ebgconsulting.com/, or who have emailed a request to be added.

EBG Consulting, Inc. does not sell, rent, or loan subscriber information to any third party.